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SPECIFICATION 



TITLE OF THE INVENTION 



METHOD FOR BANDWIDTH RESERVATION IN DATA NETWORKS 



BACKGROUND OF THE INVENTION 
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The present invention relates to bandwidth reservation in data networks, in 



particular for transmitting multimedia data m computer networks such as the Internet. 

The Internet makes broad use of the connection-oriented protocol TCP/IP 
which, in turn, uses the underlying Internet Protocol, IP for short. IP, for its part, is a 
datagram protocol whose datagram property allows for it to be administered and scaled 

10 very easily and has, therefore, made an important contribution to the success of the 
Internet. However, a datagram protocol, such as IP, in particular, has the drawback 
that an assurance for a transmission is given neither generally nor in a particular 
volume of data in a particular time. This is called "best effort", on the basis of which 
each network node makes the best possible attempt to forward the data pockets, which 

15 dispenses with a guaranteed level of reliability. Where the latter is required, a protocol 
in the layer above, such as TCP/IP, therefore provides a reliable connection using 
repetitions, state messages and time sequences. For the majority of applications to 
date, this improvement is sufficient. Such an assurance is referred to as quality of 
service. Accordingly, TCP/IP provides the quality of service that the messages are 

20 actually received and are received in the order of sending so long as the underlying 
layer is actually working; i.e., the coimection is not signaled as being faulty. 

The transmission of telephony and, in particular, moving pictures requires a 
further quality for the transmission, however In particular, this includes the data being 
transmitted within a particular time. In the knowledge of this maximum delay time, 

25 the receiver is able to set up an adequate buffer and, thus, to ensure smooth display of 
moving pictures. 

This improvement in the transmission assurances in networks is examined 
under the headword "Quality of Service". As an overview combining the general 
knowledge of the person skilled in the art in this field, mention may be made of the 



30 book by P. Ferguson and G. Huston, "Quality of Service", Wiley & Sons 1998 
(ISBN 0-471-24358-2). 



To reserve such connections on the Internet, the protocol RSVP is provided, 
which is described in the document "Resource Reservation Protocol (RSVP)" by 
R. Braden et ai., RFC 2205, September 1997. RSVP is responsible only for setting up 
the reservation To specify the operating parts themselves, in this case the quality of 
5 service, RSVP in principle allows the use of a number of protocols; for example, the 
protocol descnbed in the document "Specification of Guaranteed Quality of Service" 
by S. Shenker et al., RFC 2212, September 1997, This document describes the 
operating parts to be reserved using parameters of the "token bucket" model. 

Studies in this area also have been published in the article "Efficient Support of 

10 Delay and Rate Guarantees in an Internet" by L. Georgiadis et al., SIGCOMM 1996, 
pp. 106-116. The "token bucket" model used therein was chosen as a largely 
unspecific model which is also intended to permit appropriate specification of data 
with a nonuniform data rate. Data with a nonunifomi data rale are, in particular, video 
data compressed on the basis of MPEG2, where not only full key frames but also much 

15 smaller change frames are transmitted. In the absence of other mles, the reservation 
needs to be geared to the large key frames for such data streams. 

It is an object of the present invention to make it possible to determine the 
parameters for reserving transport of, in particular, multimedia data in a better way 
than previously and to specify how the associated parameters are expediently 

20 interchanged. 

SUMMARY OF THE INVENTION 
To describe the multimedia data, the solution uses a repetitive sequence of 
frame sizes and their time intervals. From this sequence, the optimum parameters for 
reservation with RFC 2212 can be determined using simple analysis or simulation. 

25 Accordingly, in an embodiment of the present invention, a method is provided 

for bandwidth reservation for transmitting source and data of varying data rate in a data 
network in which transmission quality determinable in advance can be reserved, 
wherein the method includes the steps of: determining for the source data stream, 
source parameters in the form of a repetitive sequence of maximum volumes of data 

30 and associated times; determining a minimum bandwidth from the source parameters 
by dividing a total volume of data by a total time per sequence; using a simulation, for 
a reserved bandwidth which is not smaller than the minimum bandwidth, to determine 
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a buffer size and, optionally, a maximum bandwidth; and reserving the bandwidth 
using the determined stream parameters of the minimum bandwidth, the maximum 
bandwidth, the buffer size and the reserved bandwidth. 

hi an embodiment, the method further includes the step of converting source 
5 parameters available as a first sequence of block sizes and associated time intervals 
into a second sequence of transmitted volumes of data and respective time elapsed, and 
vice versa. 

In an embodiment, for a series of transmitted volumes of data and associated 
times since the start of the sequence, the simulation subtracts from the volumes of data 
1 0 the respective product of instant and reserved bandwidth and outputs a maximum as 
the buffer size. 

hi an embodiment, the simulation forms quotients of block size and associated 
time intervals and outputs a maximum as the maximum bandwidth. 

hi an embodiment, the stream parameters are determined from the source 
1 5 parameters at a transmitter. 

hi an embodiment, the stream parameters are determined from the source 
parameters at a receiver. 

In an embodiment, the stream parameters are determined from the source 
parameters at a transmission node located in a path between transmitter and receiver. 
20 Additional features and advantages of the present invention are described in, 

and will be apparent from, the following Detailed Description of the Invention. 
DETAILED DESCRIPTION OF THE INVENTION 
The present invention is described below using an example for transmitting 
video data via digital connections between computers. 
25 Video data generally include a series of frames which need to arise, be 

transmitted and be provided for reproduction at uniform intervals. In digital systems, 
the frames are preferably compressed at the transmitter by a factor of 10, for example. 
The method used in the MPEG standards relevant in this context corresponds to the 
JPEG method known for single frames. If only the single frames are compressed using 
30 JPEG, this is also referred to as M-JPEG. 

The receiver decompresses the data and displays them on a screen. In this 
context, it is indispensable for the decompressed single frames to be available for 
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display at uniform intervals again so that moving pictures do not "jolt". For this 
reason, a buffer is generally provided which normally stores a number of frames ready 
for retrieval. In terms of fiinction, the buffer may be part of the data transmission 
device or may be provided by the display program. 
5 To determine the buffer size, it is necessary to know the difference between the 

shortest and the longest delay between delivery of a frame by the transmitter and 
provision in the receiver. To simplify matters, the text below assumes that the shortest 
delay is zero, since the absolute delay is of little importance to the matters of concern 
here. 

10 Provided that the data are to be transmitted using an IP protocol such as UDP, 

the problem is that they normally contain no specifications relating to execution times. 
This method of operation is called "best effort". 

One of simplest measures is to guarantee a prescribed bandwidth, as is the case 
for an ISDN B-charmel, for example. This method is appropriate for conventional 

15 video data, where each frame is compressed individually and is transmitted in the fixed 
time frame; the bandwidth required is simply the maximum compressed frame size 
divided by the interval between the fi-ames. For typical television signals, a 
compressed frame size of 40 kbytes and an interval of 20 msecs are provided, which 
corresponds to a bandwidth of 2 Mbytes/sec. Video conferences, which use two 

20 bundled ISDN chaimels, for example, reduce the fiwne size and the frame rate to give 
128 kbits/sec. This bandwidth is then also used continuously, however, so that the 
delay on the link varies little and is easy to predict. It should be pointed out that, with 
varying delays, the receiver requires a large buffer and can start reproduction only after 
the buffer has been filled, whereby a very noticeable delay arises in the case of video 

25 conferences. The introduction of video data compression based on the MPEG standard 
results in not only fiill (compressed) frames being transmitted, however, but also those 
which code only the differences between successive frames and are accordingly much 
smaller. By way of example, a typical succession includes eight frames at an interval 
of 20 msecs with the sizes 40 kbytes, three times 10 kbytes, one times 20 kbytes and 

30 three times 10 kbytes. The mean bandwidth is now just 120 kbytes per 160 msecs; that 
is to say, just 750 kbytes/sec. Although the mean bandwidth required is smaller, the 
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maximxim bandwidth of 2 Mbytes/sec determined by the largest frame needs to be 
reserved for transmission. 

For ATM networks (asynchronous transfer mode), the article "Analysing 
Multimedia Traffic in Real-Time ATM Networks" by M. Sjodin and H. Hansson, 
5 Proc. 5th Real-Time Tech. and Appl. Symposium, RTAS'99 has therefore proposed a 
method which can be used at the nodes of an ATM network and can be used to reduce 
the bandwidth requirement in the case of a given characteristic of the multimedia data 
stream. However, this method is based on ATM networks in which virtual 
connections are set up and the data are fragmented by the network into very small units 

10 of 48 bytes, called cells. 

As already mentioned above, extras have been specified for transmitting video 
data using IP protocols. These extras include a protocol which can be used' to stipulate 
a data transmission path in the network such that guaranteed, i.e. predetermined and 
specified, delivery of transmitted data is ensured. This is the "Resource Reservation 

15 Protocol", RSVP for short, which is described in the document RFC 2205 (Braden et 
al., 1997) already cited above. With RSVP, the transmitter of a data stream transmits a 
message via the network to the receiver (or receivers). This message contains a 
specification of the quality of service required and at the same lime determines a path 
through the network from the transmitter to the receiver. The receiver responds with 

20 complemented or modified parameters and, when this message arrives at the 
transmitter as intended, obtains a reserved path having guaranteed transmission 
properties. To describe the quality of service, QoS for short, RSVP allows various 
specifications; for example, that in accordance with RFC 2212 (Shenker et al.. 
Specification of Guaranteed Quality of Service, 1 997). 

25 When using PRC 2212 to describe the quality of service, a quasi-continuous 

model is used which is called the "token bucket model". In this case, there is a buffer 
which is emptied at least using the reserved bandwidth. The buffer can be filled at a 
relatively high data rate, with the mean data rate naturally not being able to be above 
the data rate specified for emptying; i.e., the reserved bandwidth. The description of 

30 the quality of service on the basis of the "token bucket model" has the advantage that it 
is independent of the implementation of the switching nodes. 
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The RFC 2212 cites five parameters to be specified by the receiver setting up 
the connection. These are: 

r: the mean bandwidth (token bucket rate) 

R: the reserved bandwidth 

b: the buffer size (token bucket depth) 

p: the maximum bandwidth (peak rate) 

M: the maximum packet size 

This then guarantees a maximum delay of 



b-M p-R M 

10 rf= — + — 

R p-r R 



For the example cited above, the mean bandwidth obtained is 
r = 750 kbytes/sec and the peak bandwidth obtained is p = 2000 kbytes/sec. The 
reserved bandwidth R must in all cases be greater than or equal to the mean 
1 5 bandwidth; thus, by way of example, a bandwidth of R = 1 000 kbytes/sec may need to 

p-R 

be reserved. The factor thus gives 0.8. 

p-r 

Two variables, namely b and M, remain to be defined. M obviously needs to 

be chosen to be 40 kbytes, since this is the largest frame. Space for all eight frames is 

provided as the buffer, that is to say b = 120 kbytes. In that case, 

l20A:-40/t 40/t 

20 6 = — -— — 0.8+-—-—= (64 + 40)w sec = 1 04w sec 

lOOOit lOOOA ^ ' 

is obtained. 

With this choice of these parameters, the receiver therefore needs to provide a 
25 buffer for six frames. 

For the rest, the mean bandwidth is at the same time the smallest bandwidth or 
minimum bandwidth, since it is not possible to accumulate data which have not yet 
been transmitted. 
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However, it is possible to determine the parameters within much narrower 
limits and, thus, both to reduce the delay and to achieve better utilization of the 
network. 

In this context, the data stream used as an example above is represented as a 
5 tuple (40k, 10k, 10k, 10k, 20k, 10k, 10k, 10k) together with the frame interval of 
20 ms. This tuple describes a sequence of data blocks which is repetitive; i.e., is 
repeated cyclically The maximum data rate is obtained unchanged as the quotient of 
the size of the largest block and the frame interval. Equally unchanged, the minimum 
bandwidth is the sum of the block sizes divided by the total duration of the sequence. 
10 Determination of the buffer size now takes into account the fact that the data 

are forwarded at least using the reserved bandwidth R, and no buffer is required for the 
forwarded data. A simulation therefore determines the respectively required buffer 
size in the following maimer: 

first, the sequence details are accumulated into a succession in which the 
15 transmitted volumes of data are assigned to the respective time which has passed. 
This table then has the following appearance for the example: 



25 



00ms 


40k 


20ms 


50k 


40ms 


60k 


60ms 


70k 


80ms 


90k 


100ms 


100k 


120ms 


110k 


140ms 


120k 



Each row is obtained from the previous one by addition of the respective time 
difference, which is constant in this example, and the respective block size, the size of 
the first block actually appearing in the first row at the instant 0. A fiirther column is 
30 now added which determines the volume of data already transmitted for the bandwidth 
R which is to be reserved, and the volume of data is subtracted from the received 
volume of data in the fourth column: 
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OOms 


40k 


0 


40k 


20ms 


50k 


20k 


30k 


40ms 


60k 


40k 


20k 


60ms 


70k 


60k 


10k 


80ms 


90k 


80k 


10k 


lOOms 


100k 


100k' 


0 


120ms 


UOk 


120k 


0 


40ms 


120k 


140k 


0 
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For this example, one bufFer is found to be sufficient for the first largest block; 
that is to say, b = 40 kbytes. The following is then obtained: 



40000 - 40000 40000 

b= 0.8+— — = 0 + 40 = 40/n sec; 

1000 1000 

15 

that is to say, a much smaller assured delay. 

In most cases, however, a block size of 40 kbytes is not admissible. The 
relevant detail m this instance is the maximum transmission unit, MTU. In local area 
networks, such as Ethernet, this is normally approximately 1 kbyte. To make the 
20 subsequent examples easier to understand, a block size of 8 kbytes will be used 
instead. 

The first block of 40 kbytes is expediently split into 5 blocks of 8 kbytes in the 
transmitter. This then results in a correspondingly shorter time interval of 4 msecs per 
block. The above table is then obtained as follows: 

25 



30 



OOms 


8k 


0 


8k 


04ms 


16k 


4k 


12k 


08ms 


24k 


8k 


16k 


1 2ms 


32k 


12k 


20k 


16ms 


40k 


16k 


24k 


20ms 


48k 


20k 


24k 
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24ms 


50k 


24k 


26k 


28ms 


50k 


28k 


22k 


32ms 


50k 


32k 


18k 


36ms 


50k 


36k 


14k 


40ms 


58k 


40k 


18k 


44ms 


60k 


44k 


16k 


48ms 


60k 


48k 


12k 



For the sake of clarity, the other rows have been omitted. A buffer of 26 kbj^es 
10 is found to be sufficient. 

Hence, b=26k and M=8k are obtained; the assured maximum delay is reduced 

to 



26k ~ 8/t 8/fc 

0.8 + — - = (18 - 0.8 + 8)/w sec = 23w sec 

b= 1000/t 1000* ^ ; 



15 

i.e., in the order of magnitude of an additional frame. 

A prerequisite in this context is that the transmitter or the network software in 
the transmitter also sends the packets in the provided interval of 4 ms. 

If this tight condition is to be alleviated and the interval is to be reduced to 
20 2 msec, but the block size of 8 kbytes is to be retained, the following simulation is 
obtained: 



00ms 


8k 


0 


8k 


02ms 


16k 


2k 


14k 


04ms . 


24k 


4k 


20k 


06ms 


32k 


6k 


26k 


08ms 


40k 


8k 


32k 


10ms 


40k 


10k 


30k 


1 2ms 


40k 


12k 


28k 


14ms 


40k 


14k 


26k 
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16ms 


40k 


16k 


24k 


1 8ms 


40k 


18k 


22k 


20ms 


48k 


20k 


28k 


22ms 


50k 


22k 


28k 


24ms 


50k 


24k 


26k 



The buffer size is determined by the simulation to be 32 kbytes. The maximum 

D — R 

bandwidth is doubled to p=4000 kbytes/sec; the factor becomes 0.93. For the 

p-r 

10 delay at b=32k, the following is then obtained: 



. 32* - 8k 8k 



Obviously, the simulation is able to ascertain the correct buffer size for a large 

15 number of variants. 

It is admissible to specify an "infinitely" large maximum bandwidth; this 
p ^ ^ 

produces the factor « 1 and d= — 

p-r R 

The assured maximum delay now depends only on the buffer size and becomes 
20 shorter the smaller the buffer size is. It easily can be determined by the simulation. 

On the basis of the RSVP protocol, the receiver determines the bandwidth to be 
reserved by specifying the bandwidth which is to be reserved and the buffer size. 
Hence, the source parameters are preferably transmitted from the transmitter to the 
receiver, and the simulation is performed at the latter. In RSVP, transmission of such 
25 additional data is provided. Alternatively, the transmitter may actually perform such a 
simulation in order to select bandwidths which arc to be received and may then 
transmit a selection of bandwidth and buffer size, based on a block size and minimum 
interval between the blocks, to the receiver. This is possible either within the context 
of RSVP using other data or via a further network connection. 
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It is also possible for the network nodes to access the source parameters 
transmitted using RSVP and then to ascertain the buffer requirement themselves using 
a simulation. This is important particularly when the data streams are reshaped at the 
network nodes. By way of example, a different transmission medium is used between 
5 the network nodes than fi-om the transmitter and to the receiver. It is then possible to 
determine the buffer required using a simulation when setting up the connection for the 
network nodes. 

Altliough the present invention has been described with reference to specific 
embodiments, those of skill in the art will recognize that changes may be made thereto 
1 0 without departing from the spirit and scope of the invention as set forth in the hereafter 
appended claims. 
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